An ABAC policy defines access control permissions based on the attributes of the subject, of the resource, and of the action that the subject wants to perform on the resource (e.g., read, write). A resource may be, inter alia, a portion of a personal storage quota, a business unit storage quota, an information retrieval system, a (portion of a) database, an online service, a protected webpage or a physical device.
There currently exist general-purpose AC languages that have the richness to express fine-grained conditions and conditions which depend on external data. One particular example of an AC language is the eXtensible Access Control Markup Language (XACML) which is the subject of standardization work in a Technical Committee of the Organization for the Advancement of Structured Information Standards (see http://www.oasis-open.org). A policy encoded with XACML consists of functional expressions in attribute values, and the return value (decision) of the policy is one of Permit, Deny, Not Applicable, or Indeterminate. An XACML policy can apply to many different situations, that is, different subjects, resources, actions and environments and may give different results for them. The XACML specification defines how such a request is evaluated against the policy, particularly what policy attributes are to be evaluated or, at least, which values are required to exist for a successful evaluation to result. Key characteristics of this evaluation process are that the request (the query against the policy) must describe the attempted access to a protected resource fully. In practice, it may be that the request is constructed in multiple stages by different components, so that a PEP (Policy Enforcement Point) provides only some initial attribute values and a PDP (Policy Decision Point) or other components can dynamically fetch more values from remote sources as they are needed.
XACML-based solutions typically introduce “authorization as a service” whereby a Policy Enforcement Point (PEP) within a target application/system captures access requests in real time and sends them to a Policy Decision Point (PDP) for evaluation against one or more XACML policies. In practice, however, many organizations have a broad range of legacy systems for which there are currently no PEP components available, and whose authorization mechanisms are built around models other than ABAC.
However, the legacy systems referred to above are based on models which are incompatible with ABAC formats, including the XACML format, but may be configured to associate permissions with (groups of) subjects and (groups of) resources. In order to still be able to define ABAC policies and thus leverage on the ABAC approach, it would be necessary to convert each ABAC policy into an equivalent configuration of the legacy access control system that preserves the intention of the ABAC policy. Such conversion, which is preferably repeated after each policy update, includes (i) defining groups of subjects and resources, and (ii) associating permissions to subject and resource groups by evaluating the policy. Since the various permissions in respect of one resource may vary depending on the action to be taken and on environment variables, it may be necessary to duplicate each resource element into several instances. For example, the permissions in respect of a resource element file1 may be expressed as permissions for the imaginary resource elements file1_read, file1_write_localaccess, file1_write_remoteaccess etc., so that each resource gives rise to several vectors over a product of different categories (in this case: Resource×Action, Resource×Action×Environment and Resource×Action×Environment, respectively, where Environment is the category of attributes that describe the context of the access).
Simple calculations reveal that considerable numbers of such groups of subjects and resources (or more generally, n-tuples of elements) arise already in mid-size organizations with a few hundreds of users. A conversion algorithm that scales linearly with respect to the number of groups will imply a large computational load, especially if the policy is updated frequently.
Considering the field of AC policy management more generally, the applications published as U.S. 2009/0077621 A1 and U.S. 2009/0178107 A1 are relate to conversion of AC and security policies into XACML format. With reference to an information technology (IT) system for which a high-level policy exists, U.S. 2009/0077621 A1 describes a process in which a functional model for the IT system is determined. The functional model indicates functional system attributes of the IT system. Pre-configured rule templates are loaded, and low-level machine-enforceable rules are generated in a manner compliant with the high-level security policy by iteratively filling the rule templates with functional system attributes indicated by the functional model. Once generated, the machine-enforceable rules can be distributed to enforcement entities, e.g., an intrusion detection system. This application mentions XACML as a language suitable for expressing said machine-enforceable rules. U.S. 2009/0178107 A1 describes a conversion process from a source policy data structure belonging to an AC system in which primary authorizations can be subject to auxiliary constraints into a corresponding data structure for a single-authorization-query AC system. An XACML system is an example of such a single-authorization-query AC system.
U.S. 2010/0237579 A1 relates to the problem of partially serializing an XACML policy into two predicate sets: dset contains all requests (triples of subjects, actions and resources) for which the policy evaluates to Deny; pset comprises all requests for which the policy evaluates to Permit. The document does not distinguish between the two possible further decisions, Not Applicable and Indeterminate, hence will not separate the possible requests accordingly. The proposed algorithm by which the serialization is to be achieved relies on traversing the XACML hierarchy linearly. In relation to this disclosure, the invention improves the computational efficiency.
U.S. 2007/056019 A1 is concerned with Universal Authorization Language (UAL) and discloses a technique for translating a UAL object into an access control list. As this document acknowledges, UAL is a subset of the XACML language in the sense that it allows a single PolicySet, a single combining algorithm and is significantly restricted in further respects. It is not clear whether the approach outlined in this document to convert the policy rules into disjunctive normal form before the computations start—could be applied to a complete XACML policy. In any event does the conversion into disjunctive normal form in no way optimize the computations, which would instead scale very unfortunately with the size of the policy. In particular, the number of user groups, which are formed as a basis for the iterations, is not controlled but could apparently grow exponentially with respect to the number of attribute values. It is therefore true for this document as well that the present invention improves the computational efficiency.